home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 263 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.1 KB

  1. From: Dan Holmsand <dan@et.se>
  2. Message-ID: <311535F1.562A@et.se>
  3. X-Original-Date: Sun, 04 Feb 1996 23:40:49 +0100
  4. Path: in2.uu.net!bounce-back
  5. Date: 05 Feb 96 04:00:46 GMT
  6. Approved: fjh@cs.mu.oz.au
  7. Newsgroups: comp.std.c++
  8. Organization: Affdrsvdrlden
  9. X-Mailer: Mozilla 2.0 (WinNT; I)
  10. Subject: Re: Give operator. a chance
  11. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  12.     iQBFAgUBMRWBmuEDnX0m9pzZAQFaZwF+Nz0hDL0ZjFQkqR68m1ukpn5IONpQN/Dx
  13.     O1bPQndcrsEUbnOlmPKHjhw/SFm/eedW
  14.     =FFD/
  15.  
  16. > Dan Holmsand <dan@et.se> writes:
  17. > >Is operator.() banned from the standards discussion?
  18.  
  19. I'm really sorry for reopening this old wound, but many thanks anyway
  20. for all the answers.
  21.  
  22. My reason for asking was my own "discovery" that the STL containers and
  23. algorithms are clearly overrated - sure, they are very efficient indeed
  24. for simple objects with trivial constructors. However, if you consider
  25. a vector<vector<string> >, and insert a new element at the beginning of
  26. the outer vector, the resulting code is clearly less than efficient
  27. (copy constructing all the strings of all the vectors is everything
  28. but efficient).
  29.  
  30. That's why I was hoping for smart references to come to the rescue when
  31. needed, say by redefining the original vector as
  32. vector<smart_ref<vector<string> > >, to gain the speed benefit of a
  33. faster copy constructor, while not having to rewrite all the code
  34. involved.
  35.  
  36. #pragma dream on
  37.  
  38. Another way out would be the ability (and now I am dreaming again, I
  39. know) to tell the standard algorithms how to move an object from one
  40. location in memory to another (as opposed to copying them), say by
  41. means of a couple of simple functions - "move" and "uninitialized_move"
  42. (corresponding to the copy functions), whose default implementation
  43. would be to copy construct an object in a new place, and destroy its
  44. copy in the old location. That function could easily and safely be
  45. specialized for, say, vector<T, Allocator> and string, to be a simple
  46. copying of pointers. I guess that nearly all copy constructors could be
  47. optimized in this way, given that the old copy is guaranteed not to be
  48. destroyed nor used in the future.
  49.  
  50. In effect, a standardized "move" function would give the language the
  51. "move constructor" that the auto_ptr seems to be needing.
  52.  
  53. That should make, for example, the reshuffling of vectors and sorting
  54. of containers efficient for "move aware" objects with nontrivial
  55. constructors.
  56.  
  57. #pragma dream off
  58.  
  59. However, the real solution for me will be to ALWAYS use "pointers" in
  60. collections, since I can always, easily, and without rewriting
  61. everything change from one smart pointer (say, my current favourite,
  62. the fabulous gc_ptr<T> :-) to another (containing, say, a real T if the
  63. profiler says I can live with the copying overhead).
  64.  
  65. The fact that I can do this, without losing any efficiency and without
  66. making any hacks in the standard algorithms, has a great deal to say in
  67. favour of the proposed standard.
  68.  
  69. Thanks again,
  70.  
  71. Dan Holmsand
  72. Affdrsvdrlden
  73. dan@et.se
  74. ---
  75. [ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  76.   Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  77.   is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]
  78.